Cloud computing is rapidly changing the Internet into a collection of clouds, which provide a variety of computing resources, storage resources, and, in the future, a variety of resources that are currently unimagined. This new level of virtualization should have unbounded the physical and geographical limitations of traditional computing, but this is not yet the case.
Even with existing virtualization capabilities, businesses are faced with scaling, migration, and expense issues for their resources that operate in these cloud environments. That is, to achieve proper managed and controlled access to physical resources of these cloud environments, businesses have to manually manage and often manually schedule/plan for migrating from one cloud environment to other cloud environments.
Often an enterprise may want to only temporarily clone a cloud environment or part of a cloud on demand based on location and/or expense. For example a sales person may have setup an extensive demo involving multiple machines (part of a cloud or an entire cloud). He/she would like to convert this demo into an automated package to take with him/her on the road for demoing at customer sites without having to bring all the hardware and without determining exactly which machines were used. When the sales person gets on site he/she would like to clone and replicate the demo to the nearest cloud having the best resources available at the sales person's current location.
The sales person in the present example is likely out of luck because cloud migration from one set of hardware devices to another new set of hardware devices is presently not an entirely automated process. This is so because the resources of a cloud that are to be cloned often have hard coded machine-specific limitations (in fact this is more common than uncommon), such that simply packaging the configuration up and migrating to a new environment would likely result in numerous failures in the new environment because the hardware specific limitations are unknown and nonexistent in the new environment. So, although the migration may seem to work as soon as some of the resources are accessed failures will occur. Worse yet a hard failure or exception may not occur and a resource may appear to process but be using wrong data such that the new installation becomes very unreliable.
Enterprises are aware of this scenario and as a result, they spend a lot of time manually configuring new installations and testing new installations, which hardly saves these enterprises much time and money and clearly makes the process a largely manual process. In our sales person example, the sales person would have to arrive at the site of the demo many days before the scheduled demo and work with technology staff to ensure everything is properly configured and running as expected.
Therefore, there is a need for a more automated approach to workload coordination for migration and cloning.